Web Fetch APIのユーザー保護機構
#セキュリティ #Webサーバー・ブラウザレイヤー
後述を全体的にまとめると、Web Fetch APIは
Cross Origin Resource Sharing関連の規定により、（突破可能な不十分なものではあるが）サービス提供者とユーザーの意図しない各種リソースをロードすることによる
XSS
サイドチャネル攻撃
を抑止する
ヘッダー関連の各種の規定により、cookieをはじめとする、リクエストヘッダーに含まれるユーザー機密情報をスクリプトから隠蔽する
ことで、ユーザーの保護を図っていると言える。
なお、ウェブサイトの機密情報の保護は、サービス提供者の利権を守るだけでなく、ユーザー自身の個人情報を保護する上でも重要であるという点を忘れずに
Fetch Standard #WHATWG に記載されている情報のメモ
この仕様書のページ内検索で、以下の単語を検索し、該当場所の周辺をチェックした
secure
security
block
Server-side HTTP Requestでは実行できるが、Web Fetch APIではできないものを中心に
Cross-Origin Resource Policy
XSSの防止
機密リソースの保護
Cross Origin Read Blocking
機密リソースの保護
Content Security Policy
XSSの防止
機密リソースの保護
forbidden-method
ヘッダーに含まれる機密情報をユーザーから秘匿するための制限
forbidden-header-name
一部の接頭辞から始まるヘッダーをユーザーから隠蔽する
ユーザーエージェント開発者にセキュリティの懸念なく触れるヘッダーを提供するために設定されているようにも見える
Fetch Standard #forbidden-response-header-name
A forbidden response-header name is a header name that is a byte-case-insensitive match for one of:
Set-Cookie
Set-Cookie2
Fetch Standard #cors-protocol-examples
Alternatively, if bar.invalid wanted to share all its response headers, for requests that do not include credentials, it could use * as value for the Access-Control-Expose-Headers response header. If the request would have included credentials, the response header names would have to be listed explicitly and * could not be used.
credentialsは、Access-Control-Expose-Headersに含めることができない
違反すればエラーになる？
mixed-content
fetchのredirectパラメータによって、redirectした時に返答を無効化できる設定が可能
port-blocking
よく知られた用法のport番号には接続しないようにする
単にウェブサイト開発者の利便性の問題かな？それともそういうアタックの仕方があるのかな？